🐛 Generate warning when release notes can not be generated #9163
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
the
size/XS
|
/area release |
| @@ -447,6 +444,9 @@ func modifyEntryTitle(title string, prefixes []string) string { | |||
| // generateReleaseNoteEntry processes a commit into a PR line item for the release notes. | |||
| func generateReleaseNoteEntry(c *commit) (*releaseNoteEntry, error) { | |||
| entry := &releaseNoteEntry{} | |||
| if c.body == "" { | |||
There was a problem hiding this comment.
I'm still trying to root cause and find out if we can fix these notes up automatically. For the recent CAPV release it looks like:
The note with no PR linked is this one: kubernetes-sigs/cluster-api-provider-vsphere#1819.
- ERROR: BODY MISSING. FIX MANUALLY
- ERROR: BODY MISSING. FIX MANUALLY (#2147)
- ERROR: BODY MISSING. FIX MANUALLY (#2166)
- ERROR: BODY MISSING. FIX MANUALLY (#2176)
There was a problem hiding this comment.
The three that have PRs references:
- 🌱 Deprecate v1alpha3 and v1alpha4 apiVersions cluster-api-provider-vsphere#2166
- 🌱 Bump golang.org/x/tools from 0.11.1 to 0.12.0 cluster-api-provider-vsphere#2176
- 📖 Update release documentation & add release issue template cluster-api-provider-vsphere#2147
All appear to have been merged manually.
Not sure what happened with kubernetes-sigs/cluster-api-provider-vsphere#1819 but it has a very different merge commit: Merge branch 'kubernetes-sigs:main' into 1162
There was a problem hiding this comment.
Oh damn. Yeah that was me to unblock some Prow stuff (CI was green before I did it :))
There was a problem hiding this comment.
But I think naadir might have also done some manual merges when prow was off - wonder if there's a way you did it that made the history come out weird.
I don't think we have to worry about this too much though - fine with having a best-effort warning until this becomes a constant problem. CAPI history seems fine.
There was a problem hiding this comment.
I assume the problem is if the description is left empty (what I did)
There was a problem hiding this comment.
But it's fine. Just thought let's add some info if it's easily available. (but didn't know if the info is easily available or not :D)
There was a problem hiding this comment.
How did you figure out it was this PR?
There was a problem hiding this comment.
The issue is that the body is empty at the point the notes are generated. We could try to detect that a bit earlier, but it would involve either refactoring or looping through all the commits. IMO it's not worth doing unless this happens again - which this change will signal.
There was a problem hiding this comment.
I was guessing (without looking at the code) that when we have the body here we should also have the corresponding commit id close by :D
There was a problem hiding this comment.
Unfortunately not AFAIU
Signed-off-by: killianmuldoon <[email protected]>
killianmuldoon
force-pushed
the
pr-release-note-bug
branch
from
49dc5b6
to
92f1e9a
Compare
|
FYI @kubernetes-sigs/cluster-api-release-team - a bug we found when using the tool in another repo. |
|
/lgtm /hold Thank you for taking this over! |
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: b694efb286b3acc2665e153845c32e151be8bb90
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
Signed-off-by: killianmuldoon [email protected]
Add a warning to the release notes tool when a release note can not be generated at all - i.e. when the body is empty. We noticed this error when using the release tool to generate notes for the Cluster API provider for CAPV.
This error hasn't occured in releases of CAPI AFAICT. Running
go run ./hack/tools/release/notes.go --from=v1.4.0doesn't produce any errors.